home *** CD-ROM | disk | FTP | other *** search
/ Ham Radio 2000 #2 / Ham Radio 2000 - Volume 2.iso / HAMV2 / TCP_IP / TNOS230D / NEW2TN2.20 < prev    next >
Text File  |  1996-10-05  |  35KB  |  785 lines
  1.   TNOS Release Notes - Release 2.20
  2.   Brian A. Lantz, brian@lantz.com
  3.   v1.00, 05 October 1996
  4.  
  5.   These are the DRAFT Release Notes for release 2.20 of TNOS.  Hope-
  6.   fully, this list of changes will give you an idea of the scope of work
  7.   that has occured since the release of TNOS 2.10.
  8.   ______________________________________________________________________
  9.  
  10.   Table of Contents:
  11.  
  12.   1.      Bug Fixes
  13.  
  14.   2.      Improvements and Enhancements
  15.  
  16.   3.      Minor Changes
  17.  
  18.   4.      Remaining Known Bugs
  19.  
  20.   5.      To-Do List
  21.   ______________________________________________________________________
  22.  
  23.   1.  Bug Fixes
  24.  
  25.   The following bugs have been squashed.
  26.  
  27.   o   Fixed FTP put security hole (UNIX)
  28.      If creating a new file, the directories write permissions were not
  29.      being used to determine whether or not the action would be
  30.      permitted.
  31.  
  32.   o   AXUI callsign buffer expanded in size
  33.  
  34.   o   Fixed a buglet that crashed the system w/long nickname in convers
  35.      Only occurred with a LONG nickname when executing the '/cut'
  36.      command.  Obscure, but there.....
  37.  
  38.   o   Fixed a few assorted buglets that weren't reported before 2.10 :-(
  39.  
  40.   o   Fixed crash if corrupted wpages files are expired
  41.  
  42.   o   Fixed a subtle bug affect the pathname() function
  43.      This only affected 'finger' when using the '-d dirname' command
  44.      line option, and then not always.
  45.  
  46.   o   Fixed a minor problem with forwarding using an area rewrite
  47.      If multiple messages were being sent during an FBB or XFWD bundle,
  48.      then only the first address was being rewritten......
  49.  
  50.   o   Fixed problem with a CC: to a public area
  51.      If you send a 'SP' BBS message (or 'SC') and end up with a CC: to a
  52.      public area it has an 'X-BBS-Type' line defining it as personal,
  53.      when it should be bulletin. This only is examined when forwarding
  54.      PBBS traffic. There used to be code in TNOS (from JNOS) that made
  55.      the 'X-BBS-Type' line *the* authority on the message's type. Now,
  56.      if a message is in a public area, it is a bulletin, and the 'X-BBS-
  57.      Type' value is ignored (i.e. a 'B'ulletin will not be changed to a
  58.      'P'ersonal).  If it is public, it cannot be personal. This does NOT
  59.      prevent having the reverse, that is messages in private areas
  60.      (maybe a private storage area for an individual PBBS's forwarded
  61.      messages) being sent as bulletins.
  62.      Also, in doing this, I noticed that you COULD have a message in a
  63.      'nts' area that sometimes would NOT be sent as a 'ST' message. This
  64.      was also fixed.
  65.  
  66.   o   Fixed displaying parameter strings with a '\r'
  67.      Now, if you define a parameter string (like 'ax25 bctext') to be a
  68.      multi-line string with a '\r', the output to the screen or the
  69.      remote user will be as expected, i.e. it will look the same as
  70.      '\n'.
  71.  
  72.   o   Fixed problem with 'editheader' and messages without a X-BBS-Type
  73.  
  74.   o   Several unreported RIP bugs found (in LINT'ing) related to
  75.      broadcasts
  76.  
  77.   o   Fixed where some HTTPPBBS accesses weren't removing 'users' when
  78.      done
  79.  
  80.   o   Added a fix for supressing Polled Kiss polls on multidrop kiss
  81.  
  82.   o   Fixed convers compatibility problem with NON-TPP servers
  83.      If the callsign/nickname combo's is larger than 9 characters, this
  84.      will prevent a Jnos host that is linked in from hearing what that
  85.      person is saying. Now when speaking with a non-TPP compatible
  86.      system, the nickname should be striped off (if one was set) before
  87.      passing the data to the brain-dead server.
  88.  
  89.   o   Fixed an evasive buglet in FBB forwarding code
  90.      At times, after sending a transaction, TNOS would send another one,
  91.      without allowing the remote side to take their turn. Though this
  92.      has happened since FBB forwarding was added, it happened so
  93.      infrequently is was hard to pin down, and even when spotting it,
  94.      there didn't seem to be a pattern to it.  Well, there was ;-) It
  95.      turns out that if all messages in the negotiation bundle were
  96.      rejected, that's when this occurred. The first line of the remote's
  97.      negotiations would get eaten, and then TNOS would start a new
  98.      negotiation, in which it THOUGHT that the remainder of the remote's
  99.      negotiation was an invalid response. All fixed now!
  100.  
  101.   o   Fixed a rare bug with the at command
  102.  
  103.   o   Fixed a kiss trace buglet, for multidrop kiss
  104.  
  105.   o   Fixed buglet where some forwarded personal messages weren't
  106.      deleted
  107.      They were removed from the forwarding queue, but not marked as
  108.      deleted messages This only affected FBB and XFWD sessions. This
  109.      normally didn't happen, except when a message was rejected, for
  110.      whatever reason.
  111.  
  112.   o   Fixed a discovered memory leak with FBB and XFWD sessions
  113.  
  114.   o  Forward file locking fixed
  115.      If a record got added into a *.fwd file when a forwarding session
  116.      is concluding, sometimes the new record STILL got missed, and the
  117.      *.fwd file would get deleted, losing that new record. Only happened
  118.      if the new message was in the SAME area as the area last processed.
  119.      Rare, but needed to be addressed.
  120.  
  121.   o   Fixed a XFWD trace buglet, with incoming messages
  122.      Thanks to a typo, if the 'forward xtrace' is on and a new message
  123.      comes in, there was a crash.
  124.  
  125.   o   Corrected occasional delay in noticing new messages in PBBS queues
  126.      While not bad previously, new messages MIGHT not have caused an
  127.      immediate rescan of the queue on the very next negotiation for FBB
  128.      or XFWD sessions.  Now this should always rescan on the next
  129.      negotiation.
  130.  
  131.      The net result is that (for example) if a new personal message
  132.      comes in on one forwarding session that is queued for another PBBS
  133.      that is also actively forwarding, then that message will go out on
  134.      the next negotiation (assuming that you have the personal areas
  135.      located before the public areas in that PBBS's forwarding entry in
  136.      the 'forward.bbs' file).
  137.  
  138.   o   Added Gareth's fix for incomplete nntp file crashes
  139.  
  140.   o   Fixed a parsing bug with incoming XFWD sessions
  141.  
  142.   o   Fix for possible string overflow during command line expansion
  143.  
  144.   o   LONGSTANDING DNS buglet found!
  145.      The DNS code had a subtile bug, which allows overrunning a buffer
  146.      if the address being queried returned a LONG response. This only
  147.      occured if the DNS was serving for others, and NOT for local usage.
  148.  
  149.      This one probably accounted for the assorted DNS quirks, as well as
  150.      some (possibly ALL) of the strangely corrupted memory problems.
  151.  
  152.      For example, if you queried a TNOS site (connected to the Internet)
  153.      for the address 'mx1.compuserve.com', then you would PROBABLY would
  154.      have crashed the system, 1 out of every 3 or less attempts. But a
  155.      query on a simpler address (such as 'lantz.com') would NEVER crash
  156.      it.  The 'mx1.compuserve.com' address returns *10* 'A' records, and
  157.      uses about 2K of space to store it, when previously only 1K was
  158.      being allocated.
  159.  
  160.      If your 'domain dns' is off, this would NEVER affect you. It was
  161.      not in the mainline DNS code, just in the code used when TNOS was
  162.      acting as a server for others.
  163.  
  164.      The original RFC stated that 512 bytes should be the MAX that is
  165.      returned in a DNS UDP packet, but this seems (at a quick glance) to
  166.      be being ignored (deliberately or accidently) by every server I
  167.      checked.
  168.  
  169.      For the time being, this has been changed to 4K, which should be
  170.      FAR more than enough. This will need to be revisited when I've had
  171.      time to investigate whether the RFC is obsolete or not.
  172.  
  173.   o   Fixed a problem sending ReturnReceipts to incomplete messages
  174.      There would be a crash if trying to send a ReturnReceipt to a
  175.      message that didn't contain a 'To:' header or a 'Subject:' header.
  176.  
  177.   o   Fixed a PBBS 'vm' crash with more than 30 messages
  178.  
  179.   o   Fixed a buglet with 'smtp kick <host>'
  180.  
  181.   o   Fixed a longstanding startup file/DNS problem
  182.      Several commands take a hostname or an IP address. If these are
  183.      used in the startup file, they must be used with the ip address,
  184.      NOT the hostname. This is regardless of whether or not the DNS is
  185.      already configured.
  186.  
  187.      The reason is that the multitude of command that call the resolver,
  188.      do so expecting that they will NOT be swapped out. This is NOT so
  189.      with the resolver, as a DNS response can take a while.
  190.  
  191.      In the past, this led to a quick crash, as the commands parameters
  192.      got freed before the command was finished with them.
  193.  
  194.      In this release, the restriction of no hostname usage in the
  195.      startup file remains, though now the line causing the error will
  196.      report a useful message, and a crash will NOT occur.
  197.  
  198.      If you REALLY need to have a command in the startup file using a
  199.      hostname, you can (for example) do a:
  200.  
  201.              nntp add ko4ks 3600 *
  202.  
  203.   like this:
  204.  
  205.           at now+0001 "nntp add ko4ks 3600 *"
  206.  
  207.   It will delay it's action by 1 minute, though.
  208.  
  209.   o   Fixed incorrect paging in 'nntp read' newsgroup reader
  210.  
  211.   o   Fixed XFWD email 'PBBS' name and dups scanning
  212.      Previously, all received email from XFWD sessions came in as if it
  213.      came from a PBBS named 'import', since it was being processed by
  214.      the import code. Now it properly identifies the PBBS sending it.
  215.  
  216.      Also, it was discovered that the setup for the import call did not
  217.      set enough options to allow the message to be properly scanned for
  218.      R: line dups, if ALTERBID is enabled. Now this is fixed.
  219.  
  220.   o   Fixed NNTP code that was improper in view of RFC977
  221.      If an 'IHAVE' failed, the connection was aborted. RFC977 states
  222.      that if a server has a problem with an 'IHAVE', it can report an
  223.      error, or just drop it silently. It should NOT need to abort. And
  224.      all xNOS NNTP servers would have then gotten into a loop, as an
  225.      aborted session did not update the 'poll' files polling time. This
  226.      would NOT remove the erring message from those that it would try to
  227.      send (unsuccessfully) next time, in a loop until humans intervened.
  228.  
  229.      Aside from that, aborting due to a single rejected posting (via
  230.      IHAVE) is NOT efficient, as the two sites MAY only connect once or
  231.      so a day.  Postponing VALID news articles because of one INVALID
  232.      one is not acceptable. If PBBS forwarding aborted a session due to
  233.      rejecting a single message, SYSOPs would be screaming ;-)
  234.  
  235.      The loop had already been found and fixed in this TNOS release, but
  236.      now the bad message sent via 'IHAVE' will not cause an abort.
  237.  
  238.   o   Added incoming negotiations from XFWD to log file (an oversight)
  239.  
  240.   o   Added code to delete incomplete PBBS messages from forwarding
  241.      queues
  242.      If the forwarding code sees a message without a 'To:' and 'From:'
  243.      field, then that message is deleted from the forwarding queue.
  244.      Previously, this message could not be forwarded (obviously) but it
  245.      also did not get removed from the forward queues, without sysop
  246.      intervention.
  247.  
  248.   o   FOUND THE ELUSIVE "gateway no-timeout disconnect" bug!
  249.  
  250.   o   Added a few pwait()'s to the fwding code, it was greedy at times
  251.  
  252.   o   Also refresh 'pbbs tdisc' counter during gatewaying for incoming
  253.      data
  254.  
  255.   o   PBBS gatewaying now yields to 'pbbs maxtimer' setting, if used
  256.  
  257.   o   All the above items included in beta release 2.20b1
  258.  
  259.   o   Fixed NNTP buglet with multiple "GMT"s in a NEWNEWS command line
  260.  
  261.   o   Fixed NNTP bug in code gatewaying PBBS->NNTP messages
  262.  
  263.   o   Fixed a bug in the IMPORT code
  264.  
  265.   o   Fixed an FTP server buglet (in Unix)
  266.      The security patches weren't complete, and you COULD do an 'ls' on
  267.      a directory which didn't allow reading in it's permissions.
  268.  
  269.   o   All the above items included in beta release 2.20b2
  270.  
  271.   o   Fixed a buglet in the NNTP code that could trash the 'domain
  272.      trans' setting
  273.  
  274.   2.  Improvements and Enhancements
  275.  
  276.   The following optimizations and improvements have occurred.
  277.  
  278.   o   Added a 'security createsecure' command, for securing new file
  279.      creation
  280.      This boolean command sets whether the 'security createperms',
  281.      'security createuid', and 'security creategid' commands are to be
  282.      used.
  283.  
  284.   o   Added a 'security createperms' for new file creation permissions
  285.      (UNIX)
  286.  
  287.   o   Added a 'security createuid' for new file creation user ID (UNIX)
  288.  
  289.   o   Added a 'security creategid' for new file creation group ID (UNIX)
  290.  
  291.   o   Added a 'MINIDLE' attribute to the PBBS forward.bbs for each entry
  292.      For each BBS in the forward.bbs file, their MINIDLE attribute is
  293.      set to the value of the 'forward minidle' command. This value can
  294.      be overridden for each BBS by setting it's own 'MINIDLE' attribute.
  295.      This allows you to set some BBSs with short retry intervals, while
  296.      other ones can be set with long intervals. By using this, and
  297.      setting the 'forward timer' to a short value, you can have
  298.      different connection intervals for each BBS.
  299.  
  300.   o   Added to forwarding, code to limit time of fwding session
  301.  
  302.   o   Added a 'forward limittime' command to set default max session
  303.      time
  304.  
  305.   o   Added a forward.bbs LIMITTIME attribute to override default
  306.  
  307.   o   TNOS/DOS no longer supports BorlandC - Now uses DJGPP!
  308.      Many reasons for this change:
  309.  
  310.      1. This is a FREE compiler
  311.  
  312.      2. It is easy for anyone to acquire
  313.  
  314.      3. It is the MSDOS port of the GNU C compiler, so the same compiler
  315.         will be used for both Unix and MS-DOS compiles.
  316.  
  317.      4. The source tree will be able to be simplified
  318.  
  319.      5. It contains its own DOS extender, allowing a linear memory map
  320.         (no 640K conventional memory limitation)
  321.  
  322.      6. It will use as much memory as you have, as long as you have a
  323.         memory manager that supports DPMI (and a free one is available
  324.         for use with DJGPP applications)
  325.  
  326.      7. TNOS/DOS users will be able to compile in EVERYTHING that they
  327.         want!  NO MORE 'DGROUP exceeds 64K' compiler errors.
  328.  
  329.      By the time this release goes public, all you need to know will be
  330.      put together to make it painless for the user or the individual who
  331.      WANTS to compile their own. There will be no NEED to compile your
  332.      own, though.
  333.  
  334.      And as of this release, I WILL resume making production MS-DOS
  335.      executables available, though only one will be supplied, with most
  336.      everything compiled.
  337.  
  338.      And Team TNOS will be MORE than glad to do custom compiles for
  339.      those who wish a smaller executable, if needed. Custom compiles
  340.      with DJGPP are no more effort than under Unix.
  341.  
  342.      Some Borland-specific code has already been removed, and more will
  343.      soon.  TNOS is now a BorlandC-free zone ;-)
  344.  
  345.   o   Added a 'forward reload' command
  346.      This should allow a way to eliminate the occasional crash if a BBS
  347.      was added or deleted from the 'forward.bbs' file and the system
  348.      wasn't aware of that change. This is NOT needed for changes within
  349.      an already defined PBBS in the file, but should be executed when
  350.      PBBSs are added or deleted to a running system, as soon as the
  351.      change is made.
  352.  
  353.      Using this command also clears the 'forward laston' times and will
  354.      affect the 'forward minidle' and MINIDLE attributes for the PBBS
  355.      defined in the forward.bbs file. None of these is terminal; this is
  356.      mentioned as a caviat.
  357.  
  358.   o   Added logic to forwarding code in determining if BBS is connected
  359.      Previously, if a user was connected to the PBBS with the same name
  360.      as an outbound forwarding BBS, the session would be skipped, even
  361.      if this was the actual USER of that remote BBS visiting your
  362.      system. While that USER was connected, traffic would backup on your
  363.      system. This also was the same if the remote BBS used your system
  364.      to gateway to forward to another system.
  365.  
  366.      Now if the USER seems to be on the system, the data from that user
  367.      is analyzed to see if we have received a PBBS SID. If not, then
  368.      this cannot be a forwarding session (at least, not yet), and the
  369.      outbound connection is allowed.
  370.      While their is the outside chance of an inbound and an outbound
  371.      both occuring at the same instant, they would be no problem in that
  372.      happening.
  373.  
  374.   o   Added PPPIPIP option 3, for use with Windows NT servers.
  375.  
  376.   o   Added a 'pbbscmd norreceipt' command to disable ReturnReceipt
  377.      responses
  378.  
  379.   o   Added expiration of NNTP newgroups New commands are:
  380.  
  381.              nntp expire articles <expiry in days> (default 28)
  382.              nntp expire bids     <expiry in days> (default 56)
  383.              nntp expire now      kicks the nntp expire process into action.
  384.  
  385.   The first two determine the age of articles and bids to be expired by
  386.   the 'nntp expire now'.
  387.  
  388.   To do the expiration automatically at a set time, add a cron entry for
  389.   it.
  390.  
  391.   o   Added a 'nntp rline' command - Thanks Gareth
  392.      Determines whether R: lines are preserved when moving PBBS messages
  393.      to NNTP.  When off, R: lines passing through the pbbs->nntp gateway
  394.      are stripped of their R: Lines, and the BBS callsigns are added to
  395.      the Path: line.
  396.  
  397.      When on: R: lines are left in place, and BBS calls are not added to
  398.      Path.
  399.  
  400.      The default is on. The R: line stripper only operates on bulletins
  401.      gatewayed from your PBBS areas on your TNOS.
  402.  
  403.   o   Added a 'forward biduknos' command
  404.      This (if enabled) will create local bids of 'xxx_<host>@hamradio'
  405.      rather than 'xxx@<host>'. For messages forwarded in via PBBS
  406.      forwarding, the bids will be 'xxxxxx@hamradio' rather than
  407.      'xxxxxx@<remotebbs>.bbs'. This is for compatibility with UKNOS,
  408.      which does it different than all other NOS's.
  409.  
  410.   o   Added code to reject messages with non-ASCII addresses
  411.      Since the PBBS spec makes these required to be ascii, TNOS will now
  412.      reject all non-ascii to and from addresses, and BIDs. Some were
  413.      received here with both callsigns as 6 '0xff' characters and all
  414.      the data characters were the same. Now those invalid messages will
  415.      be refused, at least with FBB-style forwarding.
  416.  
  417.   o   Added two NNTP subcommands 'nntp pbbs2nntp' and 'nntp nntp2pbbs'
  418.      Each of these command determine whether or not one side of the new
  419.      NNTP-to-PBBS gateway is active. If 'nntp pbbs2nntp' is on, then all
  420.      PBBS bulletins and selected personal messages will be gated into
  421.      NNTP.  If 'nntp nntp2pbbs' is on, then most NNTP messages will be
  422.      gated into the PBBS message areas
  423.  
  424.      The PBBS-to-NNTP handling uses a 'etc/news2mail' file. The format
  425.      is:
  426.  
  427.                      news.group.name    toaddress       [ distribution ]
  428.  
  429.   Any amount of white space can separate any of the fields, and comments
  430.   can be placed in that file by using a '#' as the first character on
  431.   the line. Blank lines are also ignored.
  432.  
  433.   If the user part of the address (part before the '@') is found in the
  434.   file as one of the 'toaddress' fields, then the message will be sent
  435.   to the 'news.group.name' on that line. If an optional 'distribution'
  436.   is given, then it will be used rather than the default (discussed in
  437.   the next item).  The 'distribution' string (if given) must be the
  438.   complete distribution name. If the 'distribution' is '-', then the
  439.   distribution will be created as described in the next paragraph.
  440.  
  441.   If the address is NOT found in the 'news2mail' file and it is NOT a
  442.   personal message area, then a newgroup name will be made by appending
  443.   the user part of the address to 'ampr.bbs.'. If a host portion of the
  444.   address was given (the part after the '@'), then the distribution will
  445.   be 'bbs.' with the host portion appended.
  446.  
  447.   Personal messages CAN be gated from PBBS to NNTP, but only if they
  448.   have an entry in the new2mail file. A typical entry would be:
  449.  
  450.                   ampr.mailbox.sysop      sysop      -
  451.  
  452.   All PBBS forwarded messages with a 'Message-Id:' ending in '.bbs' will
  453.   be converted to <BID@hamradio>, to accommidate for consistency in
  454.   Message IDs, and to prevent dups.
  455.  
  456.   NNTP-to-PBBS gatewaying uses the same 'news2mail' file, placing
  457.   messages into the PBBS if they are found in that file. The 'toaddress'
  458.   field is used as the user name and the host part of the PBBS address
  459.   is the last portion of the distribution header line in the news
  460.   article.
  461.  
  462.   If the NNTP newsgroup is NOT found in the 'news2mail' file, but the
  463.   newsgroup begins with 'ampr.bbs.', it is gated into the PBBS, using
  464.   the last portion of the newsgroup name as the user portion of the
  465.   address and the host part of the PBBS address is the last portion of
  466.   the distribution header line in the news article.
  467.  
  468.   Message ID's of news articles ending in '@hamradio' will be changed to
  469.   '@nntp.bbs'. All other message ID's will remain intact, and will be
  470.   treated by the PBBS forwarding code as it always has.
  471.  
  472.   All news articles NOT in the 'news2mail' file that do not begin with
  473.   the 'ampr.bbs.' prefix are NOT gated into the PBBS.
  474.  
  475.   o   Added a 'nntp defaultdist' command
  476.      This sets the default distribution used by PBBS-to-NNTP gatewaying,
  477.      if the address has a matching entry in the 'news2mail' file and
  478.      does not specify a specific distribution. This has no effect on
  479.      messages not found in the 'news2mail' file or on NNTP-to-PBBS
  480.      gatewaying.
  481.  
  482.      The default for this is 'bbs.www' for worldwide distribution.
  483.  
  484.   o   Added a 'nntp trace' command - with some activity traced
  485.  
  486.   o   Added a pre-defined 'fwd_queue' finger target
  487.      Provides the same info as the Command Session 'forward summary' or
  488.      the PBBS 'if' commands.
  489.  
  490.   o   Added a NNTPFILTER compilation flag
  491.      This uses the 'etc/wordhold.dat' file (the same one as for
  492.      HOLDMODS) to record words that are unacceptable for NNTP articles.
  493.      Any incoming articles (POST'ed or IHAVE'ed) will be checked against
  494.      this list (if the NNTPFILTER flag is compiled in), and if any are
  495.      found, then the article will be dropped, reporting the error.
  496.  
  497.      This is a long needed addition to the NNTP server, with the Amateur
  498.      licensing regulations varying as much as they do from country to
  499.      country!
  500.  
  501.   o   Added another NEW feature, that COULD be interesting!
  502.      Added an new server, which can be used in many different ways. I
  503.      like these kinds of additions, as I know that users will find many
  504.      ways to use this that I never could have imagined! (Like the
  505.      Tscript language)
  506.  
  507.      There is now a FIFO server (sorry, TNOS/Unix only), which (when
  508.      started) creates two fifos, and input one and an output one. You
  509.      can (from Unix) feed commands to the Command Session via TNOS's
  510.      input fifo, and if output is generated from the command, you can
  511.      read it from TNOS's output FIFO.
  512.  
  513.      The FIFO to input commands into TNOS is 'spool/fifo_in' and the
  514.      output FIFO from TNOS is 'spool/fifo_out'. You start the FIFO
  515.      server with a simple 'start fifo [trace]'.  If the 'trace'
  516.      parameter is omitted, then diagnostic tracing to the Command
  517.      Session is disabled. You stop the FIFO server with 'stop fifo'.
  518.  
  519.      This came from my getting tired of occasionally needing to restore
  520.      the parameters to a KISS TNC, when minor power outages occur (the
  521.      computers here are all on UPS's, but the TNCs are not. It gets to
  522.      be a regular occurance in Florida, during thunderstorm season. I
  523.      got tired of having to do a 'grep param' on my autoexec file,
  524.      grabbing it in my paste buffer with the mouse, toggling to the TNOS
  525.      Command Session, and pasting it. I wanted an easy way to send the
  526.      output of the 'grep' directly into TNOS. This can do that....
  527.  
  528.      Reading TNOS's output FIFO can be a bit confusing, if you are
  529.      dealing with an application that partially buffers input queues.
  530.      The 'tail -f' SHOULD work, but doesn't (unless you 'stop fifo' from
  531.      TNOS). But a simple 'cat /nos/spool/fifo_out' works fine.
  532.  
  533.   o   Added a new "-m" command line option, to display Feature Flags
  534.      info
  535.      This option simply returns a hexadecimal string, representing the
  536.      compiled feature flags of that executable, then it completes
  537.      execution. This hex string contains one bit for each compilable
  538.      flag, which is set if the Flag was set, or cleared if the flag was
  539.      cleared. This can help simplify reporting which features are in an
  540.      executable.
  541.  
  542.   o   Added a new executable, 'tnosmap', which decodes the '-m' output
  543.      The output of this simple executable is a list (one per line) of
  544.      all the compiled Feature Flags for the given string. This
  545.      application can either take a single hexadecimal string, or the
  546.      actual output from the 'tnos -m' command, which is the hex string
  547.      preceeded with a label.
  548.  
  549.      Unix users can easily tie this command to the previously mentioned
  550.      option, using:
  551.  
  552.              tnosmap `tnos -m`
  553.  
  554.   o   All the above items included in beta release 2.20b1
  555.  
  556.   o   All the above items included in beta release 2.20b2
  557.  
  558.   o   Added the FORTH interpreter code from SM0RGV Not sure how useful
  559.      it will be, but you can compile it in! ;-) The forth.c file
  560.      compiles with two warnings, though.
  561.  
  562.   o   Added a new conditional processing directive to forward.bbs syntax
  563.      This new one, 'if DAYOFWEEK = xx' or 'if DAYOFWEEK = xx-yy' can
  564.      allow you to limit sections of a forwarding entry to only certain
  565.      days of the week.
  566.  
  567.   3.  Minor Changes
  568.  
  569.   The following minor changes have occurred.
  570.  
  571.   o   Added code to set newly created files owner, group and permissions
  572.      (UNIX)
  573.      This is for both FTP 'put's and PBBS 'uploads'. Owner is set to the
  574.      value of 'security createuid',  group is set to the value of
  575.      'security creategid', and the file's permissions are set to the
  576.      value of 'security createperms', *IF* the 'security createsecure'
  577.      command is set to 'on'.
  578.  
  579.   o   Renamed the 'security ftpuid' command to 'security accessuid'
  580.  
  581.   o   Renamed the 'security ftpgid' command to 'security accessgid'
  582.  
  583.   o   Added code to the PBBS download command to also honor security
  584.      (UNIX)
  585.      The 'security accessuid' and 'security accessgid' values are used
  586.      (as with the FTP server) to determine whether or not the user has
  587.      permission to download the file, based on the UNIX file
  588.      permissions, as they pertain to the secured user/group
  589.  
  590.   o   Removed the 'dump' command from UNIX version
  591.      Easy way to core dump, and anyway, who REALLY would use this with
  592.      GDB around ;-)
  593.  
  594.   o   Added a new flag 'STRICT_HTTPCALL' for enforcing valid calls
  595.      w/HTTPPBBS
  596.  
  597.   o   Added use of security 'amprperms' and 'nonamprperms' w/HTTPPBBS
  598.  
  599.   o   Added a PBBS 'motd' command, to redisplay the 'pbbs motd' string
  600.  
  601.   o   Added code to the PBBS forwarding to prevent useless outgoing
  602.      connects
  603.      It the past, if there were messages queued in the forward file for
  604.      a PBBS, but they were all still being held for sysop review or all
  605.      of them were deleted messages, then a connection would be made,
  606.      even though there was no traffic that would be outgoing on that
  607.      connection. This made it work like a polled connect, but was
  608.      actually an unwanted outgoing connection.  Now these useless
  609.      outgoing connects are suppressed.
  610.  
  611.      Also added code in that section to remove the '.fwd' file if all
  612.      the remaining entries in the queue are for messages already deleted
  613.      from the system.
  614.  
  615.   o   Added code to help prevent crashes when parsing a corrupted
  616.      domain.txt
  617.      I don't know if this will prevent all of the problems, but many
  618.      sources of problems when parsing a corrupted domain.txt file have
  619.      been caught.  When these cases are found, a message is logged to
  620.      the log file, to help find the problem, listing the kind of DNS
  621.      line it encountered that had the error.
  622.  
  623.   o   Several more files LINT'ed
  624.  
  625.   o   Added a 'smtp kick' at end of outbound forwarding sessions
  626.  
  627.   o   Added code to append 'ampr.org' to abbreviated hostnames in PBBS
  628.      'send'
  629.      This applies to email addresses like 'ko4ks@ko4ks'. When seen, the
  630.      address will properly be changed to 'ko4ks@ko4ks.ampr.org', so that
  631.      rewrites that treat SMTP addresses differently can act properly.
  632.      See next entry!
  633.  
  634.   o   Added 'pbbs maildomain' command
  635.      Depending on the system, some TNOS machines prefer SMTP connections
  636.      (if possible) and others PBBS connections. This command allows you
  637.      to override the default (of PBBS addressing) and lets DNS hostnames
  638.      be used instead.
  639.  
  640.      This only comes into play for addresses like 'user@host'. In cases
  641.      like that, the 'host' portion of the address is looked up in both
  642.      the white pages and the DNS (as 'host.ampr.org'). If only one gets
  643.      found, that one will be used. If BOTH are valid destinations, then
  644.      this command will be used to determine which one is used. If 'pbbs
  645.      maildomain' is on, then the ampr.org address will be what is used;
  646.      otherwise the white pages one will be used.
  647.  
  648.      If a full DNS hostname is given or a complete PBBS haddress is
  649.      used, then this command is not used. The 'pbbs maildomain' command
  650.      is only used to complete the address used on addresses like
  651.      'user@host'.
  652.  
  653.   o   Added code to prevent a useless PBBS connection following a failed
  654.      one
  655.      If a failed PBBS session results in all remaining messages in the
  656.      queue being marked as aborted, then the next session would end up
  657.      skipping those on the first scan of the next connect (as it
  658.      should), but with XFWD (or FBB if the remote site had nothing to
  659.      send) this would result in a useless connect, as those messages
  660.      wouldn't try to get out the door at all on that session. If other
  661.      messages were in the queue, this would work as planned, but this
  662.      was a special case.
  663.  
  664.   o   MANY more files LINT'ed
  665.  
  666.   o   Added NNTP XHDR and XOVER enhancements from JNOS
  667.  
  668.   o   Removed all 'C' __ARGS() and __FARGS() macros from the source tree
  669.      While not noticable to the user, this cleans up the source tree a
  670.      lot.  It was a lot of work, but past due.
  671.  
  672.      This assumes compiling TNOS with an ANSI C-compatible compiler,
  673.      which is no longer an issue, since all TNOS support is for GCC
  674.      compilers. In this day and age, it's not really an issue, anyway.
  675.  
  676.   o   Added a 'chat' PBBS command, an alias for the 'Operator' command
  677.      I THOUGHT that this had been in there for a long time, but noticed
  678.      that it wasn't.
  679.  
  680.   o   Changed the output of 'nntp active' to two newsgroups per line
  681.  
  682.   o   Corrected the NNTP usage of GMT time
  683.      The NNTP RFC (977) specifies that the times given to commands like
  684.      NEWNEWS are to be in the SERVER's localtime, or should be in GMT
  685.      time, with 'GMT' appended to the string. The NNTP server could
  686.      handle incoming clients using 'GMT' strings, but would always use
  687.      ITS localtime when talking to a remote server. This is fine if both
  688.      are in the same time zone, but otherwise is wrong. Now TNOS's NNTP
  689.      server will use GMT strings when acting as a client.
  690.  
  691.   o   LINT'ing completed
  692.  
  693.   o   All the above items included in beta release 2.20b1
  694.  
  695.   o   All the above items included in beta release 2.20b2
  696.  
  697.   o   Added DNS patches from JNOS to allow CNAME responses to recurse
  698.  
  699.   4.  Remaining Known Bugs
  700.  
  701.   The following are known bugs that will be addressed in the near
  702.   future.  These may or may not be fixed before the next release is made
  703.   available.
  704.  
  705.   1.  The proxy server scripts do not seem to work properly
  706.      There is a problem, that is being looked into, which seems to be
  707.      related to calling scripts from within scripts (which proxy.scr
  708.      DOES).
  709.  
  710.   2.  None other at this time.... ;-)
  711.  
  712.   5.  To-Do List
  713.  
  714.   The following are things on the author's 'to-do' list that are being
  715.   considered for this or a future release of TNOS. These may eventually
  716.   be done, but not necessarily by the next release.
  717.  
  718.   1.  Finish porting the Packet driver into the new MSDOS sources
  719.      At the moment, the Packet driver is not supported for the DJGPP
  720.      compiles.  Shouldn't take too long to get ported, though....
  721.  
  722.   2.  Complete the spec and coding of the non-IP HTTP PBBS interface
  723.  
  724.   3.  Investigate incorporating into TNOS a userfs extension
  725.      This would allow *any* Linux (and possibly other Unix) program to
  726.      open a file and access certain TNOS features. For instance a
  727.      terminal program like minicom could open a device:
  728.              /tnos/connect/lan/k0zxf/ko4ks-1/813044
  729.  
  730.   and do the equivalent to 'connect lan k0zxf ko4ks-1 813044'.
  731.  
  732.   You could incorporate a copy of your current usage stats into a email
  733.   message in Pine, by simply inserting a file named
  734.   /tnos/stats/usage/general.
  735.  
  736.   4.  Add capability to allow use of OS commands
  737.      This includes finishing the incomplete 'pipe' command in the Unix
  738.      release.  Due to the obvious restrictions of MS-DOS (memory, etc.),
  739.      this WILL be considered for Unix version only.
  740.  
  741.   5.  Add better support for PBBS<->Internet mail address translation
  742.      The 'translate' file and improved handling of aliases is a START,
  743.      but more work needs to be done here. Maybe a 'translate.out'
  744.      file...
  745.  
  746.   6.  Still better handling of AUTO/LOCAL ax25 routes
  747.      Improvement by making an ax25 route entry part of the connection
  748.      block, using this unique AUTO route for this connection only.
  749.  
  750.   7.  Support (optimization) for ncurses 1.9.x for performance
  751.  
  752.   8.  Color support output to Unix console
  753.      The various color commands don't work with Unix and curses.
  754.      Annoying, but just possible unexpected output. No crashes.
  755.  
  756.   9.  Consider adding a 'R x - x' syntax to the BBS read command
  757.  
  758.   10.
  759.       Consider adding IP MASQ support
  760.  
  761.   11.
  762.       Add code to allow a TIP socket type, for use with LL Modems
  763.  
  764.   12.
  765.       Tweek the WPages code a bit
  766.      Need to improve the code that insures that the wpagebbs entries are
  767.      correct, of the proper length, and actually look like hier
  768.      addresses. Also, make the expiring of WPages files less fragile if
  769.      the file has become corrupted.
  770.  
  771.   13.
  772.       Check into duplicate entries in the WP files
  773.      While not harmful, the WPages routines SHOULD be overwritting
  774.      existing entries, NOT creating new ones.
  775.  
  776.   14.
  777.       Consider adding intelligence to convers links
  778.      The idea being that if there are no incoming links, and no local
  779.      users, that the remote outgoing link would be brought down until
  780.      this changed.
  781.  
  782.   15.
  783.       Consider added auto7+ detection
  784.  
  785.